home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0547.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  3.1 KB  |  82 lines
  1.  
  2. >Darn good question. Your approach appears to have the correct
  3. >results, but I'm not sure it's practical for many implementations
  4. >(global search-and-replace operations are inconvenient for
  5. >sequential processing models), and it certainly isn't a healthy
  6. >way to think about SGML documents.
  7.  
  8. But most browsers seem to have cacheing anyway, which means they can do
  9. global search/replace.  But you can still do it more or less sequentially.
  10. Just buffer strings of new-lines until you know what follows them, and
  11. then deal with it.  There's no method you can propose which is correct
  12. and doesn't involve storing something somewhere.
  13.  
  14. >The way to think about SGML documents, IMHO, is this: the sequence
  15. >of characters comprising an SGML document are presented to an
  16. >SGML parser, which parses the markup from the data and passes
  17. >the "results" to the processing application.
  18.  
  19. This is another alternative I considered.  But I figured that I have to
  20. deal with various parsing things when I read the HTML anyway.  I was
  21. just going to take each chunk of data, (with anchors pre-processed out)
  22. and remove all whitespace at the beginning and end (except for PRE sections
  23. and such).  But if someone put in whitespace, why should I muck with it?
  24. Who knows, they might have even wanted it there.
  25.  
  26. >>1. For each tag NOT in
  27. >>     <PRE> </PRE> <A> </A> <PLAINTEXT>
  28. >>   remove ALL surrounding new-lines.
  29. >
  30. >First, let's get one thing straight: the PLAINTEXT element as
  31. >described by the original HTML documentation is not representable
  32. >in SGML. For my purposes, I consider the HTML document to
  33. >end at the <PLAINTEXT> tag, and I consider the rest of the
  34. >data stream to be an RFC-822 message body or a MIME text/plain body,
  35. >and not SGML at all.
  36.  
  37. I hadn't meant otherwise.  But you have to read it in anyway, and since
  38. my method deals with things prior to any other parsing, you treat it
  39. all as one clump.
  40.  
  41. >Next, let's keep in mind that you can't do things like the following
  42. >global substitition,
  43. >s/\n+(<(H1|H2|ADDRESS...))>/$2/g;
  44. >because it might find things that look like tags but aren't,
  45. >for example
  46. >
  47. ><foo bar="
  48. ><H1>this is a little cooky, but nontheless legal and possible.">
  49. >
  50. >But even if you're using a proper SGML parser, consider:
  51. >
  52. ><H1>Here we go!
  53. ><a href="#xyz">click here</a>
  54. >There we went!
  55. ></H1>
  56. >
  57. >The parser will return an H1 start tag, and then the
  58. >string "Here we go!\n". At this point, your rule doesn't
  59. >tell me what to do with the newline. I have to get
  60. >the next object before I decide.
  61.  
  62. Like I said before, You have to do some sort of storage at some point
  63. anyway.
  64.  
  65. >Hmm... I guess that's reasonable. But I'd rather just pass all the
  66.  
  67. Like I said before, You have to do some sort of storage at some point
  68. anyway.
  69.  
  70. >My point is: don't use whitespace to represent significant
  71. >information except in the PRE elemnt. Use the tags that
  72. >are defined to have significance.
  73.  
  74. I suppose I agree with this more or less, at least from the point of view
  75. of generating my own code.  But we have to make something clear - can
  76. a browser keep all the whitespace if it wants to?  Or in other words,
  77. can an html generator assume collapsing whitespace, or just be aware
  78. that it might happen?
  79.  
  80.      tom
  81.  
  82.